State Machine

This topic describes the concept of State Machine.

A Finite State Machine (FSM) or finite state automaton or simply a state machine is a model of behavior composed of a finite number of states, transitions between those states, and actions.

Note: The state machine is used synonymously with state engine.
A state machine represents the sequence of states that an object goes through during its life-time in response to the events. It captures the unique characteristics of an object at distinct periods of its life-cycle and the events that trigger the changes.

Diagrams of the state machine in Unified Markup Language (UML) depict the various states that an object could be in and the transitions between those states. In many modeling languages, it is common for this type of a diagram to be called a state-transition diagram or even simply a state diagram.

A state represents a stage in the behavior pattern of an object, and like UML Activity Diagrams, it is possible to have initial states and final states. An initial state, also called a creation state, is the one that an object is in when it is first created. A final state is the one in which no transitions lead out of. A transition is a progression from one state to another and is triggered by an event that is either internal or external to the object.

A state machine is responsible for the following:

• Specifies state changes which an object performs triggered by events or signals received from other objects
  
• Specifies the reactions of the object on events
  
• Specifies actions in states
  
• Defines protocols, that is, legal sequences of operation calls of a class or interface or of interactions by signals
  The state machine has the following components:
  
• State - A state is an instance in an object's life cycle with unique characteristics.Example: A new customer applying for a credit card would be in a state 'Registered' initially and later on move to 'Verified', 'Approved' or 'Rejected'.The following are the stages in a state:
  
• Entry - The action performed when an objects enters a state. For example, sending a welcome email when the user objects come into a 'Registered' state.
  
• Do - The action performed when an object is in a state. To wait in a particular state is also a Do. For example, long running tasks can be invoked from here, like a business process model
  
• Exit - The action performed when an object leaves a state, generally you can perform cleanup sort of activities here. For example, consider a customer requesting a bank to a loan, the bank after all the verifications rejects the customers application, so before the final state we could model an activity inside the 'Exit' region to send an e-mail indicating the status of the application.
  
  
• Transition - The movement of an object from one state to another and the line linking the two states is the transition. An object moves from one state to another state in response to some events that are fired on this object's state. For example, in a customer credit card application model, when the application is verified for credit history and if it is found unsatisfactory, the concerned role or person sends a reject event to move the customer's application into a Rejected state.
  
• Transaction - Any transition between two states is in a transaction. For example, consider two states state1and state2, when the object is transiting from state1 to state2, this transition, which includes the exit of state1 and entry of state2 is performed inside one transaction. While taking the transition, if the entry of state2 fails, the object returns to the previous state1 or rather the transition never happened so the object remains in the old state.When a transition fails for some reason, state engine raises an event called state.error. In cases where the user wants to handle this exception case and may want to undo the work done on the exit or entry, he or she can do so by drawing a new transition from this state2 to a state say 'error' on the event state.error and use the entry or do activities.
  
• Guard - A guard is like a condition on a transition which allows or not allows a transition. For example, in the ATM withdrawal example, when the customer enters an invalid pin, the transition condition (guard) checks for the correct pin and accordingly accepts or rejects the transition.
  
• Activity - Activity is some work done at some pre-defined regions inside a state. For example, send a welcome e-mail when a new user registers
  
• Effect - Effect is the result of a transition. Effect is again an activity which can be performed when a transition is chosen.Consider the following example:In the above example (only a portion of the state model is shown here), a new customer comes in through two different paths. In the first path, a suspect is found and the data steward resolves the suspect and sends for update, in the second path since there are no duplicates found, the customer is directly updated into the database. Since both of them come into an updated state through two different paths, we can model an effect on the second path, where in the customer is updated automatically to send a notification to the data steward about this and this ensures that the data steward is aware of the new entries flowing in automatically.
  
• Event - Event is what triggers the transition of an object from one state to another. You can name an event , 'reject' on the credit card application model. Here trigger and event mean the same thing. A trigger is an event that initiates a transition from one state to another. 'Trigger' is the cause of the transition. An event is something that happens in time.Example - the bus has arrived.The following are the types of events:
  
• Signal Event - An object that is dispatched (thrown) and received (caught). A signal event represents a specific message that initiates a transition when an object receives the expected message (or signal).
  
• Call Event - A call event represents the dispatch of an operation. A call trigger is an event that represents the receipt of a request to invoke an operation. A transition with a call trigger initiates when the called operation is invoked. The difference between a signal event and a call event is that the transition does not start until the called operation is completed.Example - Consider a car which has in-built cruise control mode to manage the vehicle speed and other factors while driving on a lane which has strict speed limits (see below screenshot a sample state model, only a portion of it is shown here).
  
• Time Event - Time event represents the passage of a certain amount of time.Example: You could model a behavior when a new user registers himself with the web site (application) and the applications want to activate this user after 24 hours, in such cases we can model a timer event with a delay of 24 hours, upon expiry of this time, the user is automatically made active and can even send an email confirming the same.
  
  
• State Model - State model depicts the lifecycle of an object as it passes through each state. State model is the graphical representation of the behavior that is modeled for the object under consideration.Most of the terms explained above are shown in the picture below, please look into the pictorial notations of these terms, the same notations are used inside the state modeler:
  
  
  After understanding the concepts of state machine, you can now move on to understanding a state model. For information on state models, refer to State Model.